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Abstract 

Several  aspects  of  the  development  process  of  correct 
safety  critical  discrete  and  hybrid  embedded  systems 
are  discussed.  The  general  process  and  its  support 
by  the  CASE  tool  AutoFocus  is  outlined.  This  is 
illustrated  along  the  lines  of  a simplified  version  of 
NASA’s  Mars  Polar  Lander.  It  is  argued  that  spe- 
cific aspects  of  hybrid  systems  do  require  the  modifi- 
cation of  classical  theories  on  software  development, 
and  these  modifications  are  discussed.  The  paper 
concludes  by  focusing  on  one  part  of  the  develop- 
ment process,  namely  testing.  A novel  approach  to 
the  automated  generation  of  test  cases  for  discrete  as 
well  as  hybrid  systems  is  presented.  The  Mars  lan- 
der’s crash  serves  as  an  example  for  the  derivation  of 
meaningful  test  cases. 

Keywords.  Reactive  Systems,  Validation,  Devel- 
opment Process,  Automatic  Test  Case  Generation, 
CASE 


1 Introduction 

Safety  critical  systems.  Developing  correct  safety 
critical  software  for  hybrid,  embedded  systems  is  a 
difficult  and  error  prone  task.  The  functional  re- 
liability of  the  resulting  systems  is  at  least  as  im- 
portant as  security  aspects.  High  quality  of  the  re- 
sulting systems  can  only  be  achieved  using  a well 
structured  development  process.  We  present  a de- 
velopment process  that  integrates  many  methods  for 
quality  assurance  for  discrete  systems.  In  this  paper, 
discrete  systems  refer  to  discrete  event  systems.  How- 
ever, those  discrete  event  specification  techniques  we 
consider  also  have  a discrete-time  execution  model. 
For  mixed  discrete-continuous  systems  (or  ’’hybrid 
systems” ) we  discuss  elements  necessary  to  obtain  a 
similar  integrated  process,  taking  into  account  dis- 
crete as  well  as  continuous  aspects.  The  process  for 
discrete  systems  is  an  extension  of  the  V-model  [22]. 
It  is  based  on  system  models  that  are  validated  by 
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means  of  formal  techniques. 

AutoFocus.  Discrete  systems  are  modeled  using 
graphical  description  techniques  for  structure,  be- 
havior, and  interaction.  In  this  paper  we  shortly 
present  AutoFocus,  a tool  prototype  for  model- 
ing discrete  embedded  systems  that  we  will  use  to 
model  a hybrid  system,  namely  a simplified  version 
of  NASA’s  crashed  Mars  Polar  Lander.  The  mod- 
els are  based  on  a common  formal  semantics  and  can 
therefore  be  used  to  support  the  development  process 
from  the  requirements  engineering  phase  throughout 
the  test  phase.  The  existing  features  of  AutoFo- 
cus suffice  to  model  discretizations  of  hybrid  sys- 
tems. These  discretizations,  however,  usually  alter 
the  model  which  reduces  the  set  of  properties  that 
can  be  derived  from  a system  model. 

Hybrid  systems.  The  development  of  hybrid  sys- 
tems is  an  interdisciplinary  task.  Usually  engineers 
from  different  disciplines  are  involved  and  must  dis- 
cuss their  designs.  Graphical  description  techniques 
are  one  element  very  useful  to  support  this  commu- 
nication. Just  as  for  safety  critical  discrete  systems, 
it  is  furthermore  desirable  to  apply  a high  degree  of 
mathematical  rigor  in  the  development  of  safety  criti- 
cal hybrid  systems.  Today  formal  methods  for  hybrid 
systems  are  still  an  active  area  of  research,  and  there 
are  hardly  any  tools  available  which  could  yet  be  used 
in  industrial  practice.  In  this  paper  we  therefore  out- 
'Am  Vavk  fonaai  bc/cte  fcz:  dAwtvtb?.  Av/A\  as 
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tinuous systems  in  a development  process  for  hybrid 
systems  that  is  feasible  today.  We  discuss  shortcom- 
ings of  this  method  and  outline  how  our  work  on  hy- 
brid modeling  and  validation  leads  to  an  integrated 
development  process  for  hybrid  systems  which  is  close 
to  the  current  AutoFocus  approach  for  discrete  sys- 
tems. 

Testing.  Much  work  has  been  devoted  to  check- 
ing validity  and  consistency  of  a specification.  By 
now,  testing  is  the  only  practicable,  scalable  means 
of  validating  the  conformance  of  an  implementation 
w.r.t.  its  specification,  even  though  Dijkstra’s  popu- 
lar remark  that  testing  can  only  reveal  the  presence 
but  never  the  absence  of  errors  undoubtedly  holds 
true.  We  discuss  the  role  of  testing  as  a comple- 
ment to  formal  methods  and  present  a novel  approach 
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based  on  Constraint  Logic  Programming  to  automat- 
ically generating  test  cases  for  discrete  as  well  as  hy- 
brid systems.  Experimental  results  from  a case  study 
of  a safety  critical  system,  the  Mars  Polar  Lander,  are 
discussed.  We  also  take  into  account  the  integration 
of  testing  processes  into  the  development  process  of 
safety  critical  systems  and  our  method’s  benefits  and 
shortcomings. 

Overview.  The  remainder  of  this  paper  is  orga- 
nized as  follows.  In  section  2,  we  briefly  discuss  prin- 
ciples of  a software  development  process  for  reliable 
discrete  systems.  Section  3 describes  shortcomings 
of  this  classical  approach  w.r.t.  hybrid  systems  and 
suggests  modifications  that  remedy  these  shortcom- 
ings. Specifically,  we  argue  for  integrated  descrip- 
tion techniques  right  from  the  beginning.  Section  4 
then  describes  the  CASE  tool  AutoFocus  and  its 
description  elements.  Since  so  far  there  is  no  tool  sup- 
port for  the  integrated  development  process  of  Sec.  3, 
section  5 exemplifies  the  use  of  a discrete  modeling 
tool  for  a hybrid  system,  the  Mars  Lander.  Section  6 
discusses  the  generation  of  test  cases  for  discrete  as 
well  as  hybrid  systems  along  the  lines  of  our  example. 
Section  7 concludes  this  paper.  Related  work  is  cited 
in  the  respective  sections. 

2 Notes  on  the  Development 
Process 

For  safety  critical  systems,  we  advocate  a develop- 
ment process  that  heavily  relies  on  models.  In  this 
process,  models  are  developed  in  phases  known  from 
conventional  software  development  processes.  These 
models  are  then  validated,  and  the  last  step  is  to  gen- 
erate code  from  them  in  order  to  get  an  executable 
implementation.  A last  validation  step  consists  of 
testing  the  developed  systems  in  interaction  with 
their  environment,  for  example  together  with  other 
components  or  hardware.  Model  validation  is  the 
key  factor  for  producing  highly  reliable  programs  for 
safety  critical  systems.  Useful  models  should  describe 
the  developed  system  from  different  views  by  means 
of  various  hierarchical  diagrams.  The  diagrams  can 
be  used  to  capture  requirements,  architecture,  design 
and  implementation  decisions,  and  to  represent  test 
sequences. 

Model  validation  may  be  seen  as  checking  consis- 
tency. It  can  be  applied  at  several  levels:  syntac- 
tic consistency  (checking  names),  completeness  con- 
sistency (checking  references  and  types),  semantic 
consistency  (checking  refinement  relations),  and  ade- 
quacy [28,  4],  i.e.,  conformance  of  a model  with  possi- 
bly informal  requirements.  Many  available  tools  per- 
form a syntax  check  with  fixed  built-in  routines.  For 
this  purpose,  modern  tools  use  the  object  constraint 
language  OCL  [38]  of  UML  which,  in  principle,  could 
also  be  used  to  check  completeness  of  the  models.  At 


present,  CASE  tools  with  useful  semantic  checks  are 
not  available.  Recently,  model  checking  tools  have 
been  connected  to  tools  based  on  statecharts  or  SDL, 
but  due  to  the  complex  semantics  of  these  languages 
without  practical  relevance.  A systematic  generation 
of  test  sequences  is  also  not  available.  Checking  ad- 
equacy is  reduced  to  simulation  facilities. 

AutoFocus,  on  the  other  hand,  also  allows  for 
semantic  validation.  These  validation  techniques  are 
based  on  the  simple  and  intuitive  semantics  of  Auto- 
Focus [21],  and  can  be  used  to  support  model-based 
development  steps  according  to  the  V-model  within 
all  phases;  in  particular,  testing  is  supported  at  the 
design,  implementation,  integration  and  system  re- 
quirements levels. 

Modeling  hybrid  systems  with  AutoFocus  is  done 
by  a simple  discretization  of  the  continuous  behavior, 
and  this  approach  allows  to  integrate  discrete  and 
continuous  parts  in  a single  model  (as  will  be  shown 
in  the  example  in  Section  5). 

3 Hybrid  Systems 

In  this  section  we  outline  how  a conventional  formal 
tool  for  discrete  systems,  such  as  AutoFocus,  can 
be  used  within  the  development  of  hybrid  systems. 
We  discuss  advantages  and  drawbacks  of  such  an  ap- 
proach, and  present  a more  visionary  approach  not 
yet  supported  by  tools.  The  new  approach  is  sup- 
posed to  prevent  these  drawbacks.  It  results  from 
carrying  over  ideas  like  graphical  specification  with 
different  systems  views  and  model  based  validation 
based  on  formal  methods  to  hybrid  systems.  A cen- 
tral characteristic  of  the  proposed  approach  is  that 
it  is  based  on  notations  that  have  a clearly  defined 
semantics. 

A conventional  development  process.  A con- 
ventional development  process  for  hybrid  systems 
builds  upon  isolated  description  techniques  for  purely 
discrete  and  purely  continuous  components.  Pop- 
ular in  industry  are  tool  couplings  such  as  us- 
ing Statemate  together  with  Matrixx  or  the  MAT- 
LAB/Simulink/StateFlow  environment  [11,  9].  For 
the  development  of  safety  critical  systems  we  advo- 
cate the  use  of  formal  methods  and  notations  wher- 
ever possible.  This  hinders  the  use  of  current  com- 
mercial tools  like  Statemate,  ObjectGeode,  Rational 
RoseRT  or  Stateflow.  Their  notations  only  have  a 
formal  syntax,  but  the  semantics  remains  imprecise 
and  ambiguous,  or  very  complex.  A semantics  for 
the  coupling  with  continuous  tools  in  not  defined 
anyway.  However,  tools  like  AutoFocus  are  avail- 
able which  support  the  design  of  discrete  systems 
based  on  formal  notations  such  as  architecture  de- 
scriptions, extended  automata  and  MSC  dialects  [23]. 
For  continuous  systems  there  also  are  analysis  and 
simulation  tools  based  on  block  diagram  notations, 
e.g.  MATLAB  [36].  Note  that  we  regard  block  di- 
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Figure  1:  A conventional  development  process  (top)  and  an  integrated  development  process  with  hybrid  de- 
scription techniques  (bottom). 


agram  descriptions  of  continuous  systems  as  formal 
here,  because  a mathematical  model  can  be  associ- 
ated with  individual  blocks  and  their  interconnection 
in  a straightforward  manner.  (Nevertheless,  the  user 
has  to  keep  in  mind  that  the  selection  of  integration 
algorithms  for  simulation  can  have  a great  impact 
on  simulation  results  and  can  cause  them  to  differ 
strongly  from  the  mathematical  model.)  As  soon  as 
the  system  under  development  is  partitioned  into  dis- 
crete and  continuous  parts,  a formal  specification  can 
be  written  down  using  these  existing  tools,  see  Figure 
1,  top.  Well-known  techniques  from  the  discrete  and 
continuous  world  can  then  be  applied  to  the  respec- 
tive parts  of  the  model.  For  instance,  model  checking 
and  automatic  test  case  generation  may  be  used  for 
the  discrete  part  and  analysis  of  eigenvalues  for  the 
continuous  part. 


Drawbacks.  So  far,  the  only  currently  available 
technique  for  examining  properties  of  the  mixed  sys- 
tem is  simulation.  There  are  hardly  any  analytical 
methods  regarding  the  mixed  model  and  there  are  no 
techniques  which  support  design  modifications  that 
affect  both  parts  of  the  model.  In  fact  such  mod- 
ifications could  necessitate  a redesign  of  the  whole 
model. 

Furthermore,  in  such  a development  process  a 
designer  has  to  perform  a number  of  development 
steps  informally,  i.c.,  without  documenting  them 
with  clearly  defined  notations,  before  a clearly  doc- 
umented process  can  start,  i.e.,  a process  relying  on 
formal  description  techniques.  In  particular,  these 
steps  include  partitioning  the  design  into  discrete  and 
continuous  parts  which  may  involve  an  (implicit)  dis- 
cretization of  some  parts.  This  is  unsatisfactory  since 
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the  partitioning  decisions  may  be  difficult  to  alter 
later  on.  Apart  from  that,  the  resulting  coupled  dis- 
crete continuous  model  often  is  not  natural  for  some 
components  of  a hybrid  system.  For  example,  analog 
to  digital  (AD)  and  digital  to  analog  (DA)  converters, 
and  in  some  systems  the  environment,  are  inherently 
hybrid  components. 

Recommendation.  As  no  formal  hybrid  nota- 
tions with  tool  support  that  is  suitable  in  practice 
are  available  today,  there  currently  is  no  real  alter- 
native to  the  outlined  conventional  development  pro- 
cess. We  therefore  propose  to  use  informal  text  cou- 
pled with  formal  descriptions  where  possible  in  this 
process:  Writing  down  mathematical  formulae  ex- 
pressing hybrid  behavior  directly  is  hardly  reasonable 
for  bigger  systems.  In  the  context  of  AutoFocus 
we  recommend  using  architecture  descriptions  (SSDs, 
see  Sec.  4)  already  during  the  requirements  capture 
phase  and  to  describe  the  behavior  of  system  com- 
ponents informally  with  text  or,  where  practicable, 
with  mathematical  formulae,  until  the  partitioning 
into  discrete  and  continuous  components  has  been 
performed.  Figure  1,  top,  outlines  the  conventional 
process  and  its  support  by  AutoFocus.  For  the  dis- 
crete part  the  model  checking  and  testing  techniques 
already  implemented  in  the  tool  can  be  employed. 
They  enable  a more  rigorous  analysis  of  the  discrete 
part  than  what  is  possible  with  other  tools  for  dis- 
crete systems  that  do  not  have  a formal  semantics. 

Outlook:  An  integrated  development  pro- 

cess. In  a development  process  with  hybrid  descrip- 
tion techniques,  such  as  the  one  depicted  in  Figure  1, 
bottom,  the  designer  is  able  to  formally  specify  mixed 
discrete  continuous  models  at  early  stages  of  the  de- 
velopment process.  In  the  context  of  formal  methods, 
we  refer  to  “refinement”  as  altering  (or  augmenting) 
a system’s  functionality  without  violating  properties 
that  have  already  been  established.  If  validation  and 
transformation  techniques,  such  as  simulation  and 
refinement,  are  available  for  these  description  tech- 
niques, the  model  can  be  systematically  designed  to 
meet  those  system  requirements  which  affect  its  dis- 
crete as  well  as  its  continuous  aspects.  Rudimentary 
versions  of  such  techniques  already  exist  and  are  an 
area  of  current  research  (e.g.  [3,  10]).  In  later  steps 
the  model  can  be  refined  into  discrete,  continuous, 
and  possibly  some  remaining  hybrid  submodels.  For 
the  discrete  and  continuous  submodels  conventional 
techniques  can  then  be  used  to  realize  those  proper- 
ties which  only  affect  the  respective  part.  Thus,  the 
availability  of  formal  hybrid  description  techniques 
and  supporting  methods  for  them  pushes  the  point  at 
which  systematic  development,  i.e.  development  with 
formal  description  techniques,  can  begin  towards  the 
beginning  of  the  analysis  phase.  A partitioning  into 
discrete  and  continuous  submodels  can  be  postponed 
towards  subsequent  development  phases.  Such  a de- 
velopment process  with  hybrid  description  techniques 


allows  to  obtain  greater  confidence  in  the  model  be- 
fore a partitioning.  Namely,  testing  and  model  check- 
ing techniques  can  be  used  to  analyze  requirements 
and  refinement  techniques  can  be  used  to  guarantee 
some  requirements  by  construction.  By  postponing 
implementation  related  questions  changing  require- 
ments can  more  easily  be  taken  into  account.  Thus, 
errors  made  in  the  initial  development  phases  can  be 
found  earlier  and  are  therefore  cheaper  to  correct. 

The  development  process  we  propose  in  Figure  1, 
bottom,  is  based  on  description  techniques  devel- 
oped within  our  group  in  the  last  years.  For  re- 
quirements specification  and  environment  modeling 
it  uses  the  MSC-like  notation  HySC  [15],  and  the 
combination  of  architecture  diagrams  and  a hybrid 
automata  variant  which  is  subsumed  in  HyCharts 
[16].  A methodological  transition  from  HySCs  to  Hy- 
Charts is  ongoing  work  (for  similar  work  on  discrete 
systems  see  [24]).  Succeeding  steps  in  the  figure  re- 
fer to  HyCharts  rather  than  to  HySCs.  As  notations 
for  the  discrete  and  the  continuous  part  we  propose 
DiCharts  [17],  a discrete-time  variant  of  HyCharts, 
and  (continuous  time)  block  diagrams,  repectively, 
taht  can  be  integrated  easily  into  the  HyChart  nota- 
tion. 

Note  that  the  aspect  of  postponing  the  partitioning 
of  a system  into  discrete  and  continuous  parts  is  re- 
lated to  the  area  of  hardware/software  codesign  [6]. 
There,  the  decision  on  which  parts  of  a system  are 
implemented  in  hardware  and  software  is  postponed 
to  later  phases.  However,  unlike  hardware/software 
codesign  the  partitioning  into  discrete  and  continu- 
ous components  proposed  here  does  not  yet  imply 
how  the  components  are  implemented.  The  discrete 
part  could  be  implemented  in  software  or  on  digi- 
tal hardware,  the  continuous  part  can  be  turned  into 
a discrete-time  model  and  implemented  in  software 
(or  digital  hardware),  or  it  could  be  implemented  in 
analog  hardware. 

While  there  is  hardly  any  tool  support  for  the  in- 
tegrated process  today,  a close  coupling  of  discrete 
and  continuous  notations  in  the  HyChart  style  is  im- 
plemented in  the  MaSiEd  tool  [1],  which  also  allows 
simulation.  The  HyTech  tool  [18]  (or  other  tools,  e.g., 
Uppaal  or  Kronos)  which  offers  model  checking  of  hy- 
brid models  is  another  clement  needed  as  support  for 
an  integrated  development  process.  Presently,  how- 
ever, its  application  is  limited  due  to  scalability  prob- 
lems and  deficits  of  the  underlying  hybrid  automata 
model  [29].  Promising  tool  approaches  for  the  future 
should  couple  analysis  algorithms  like  those  imple- 
mented in  HyTech  with  modular  graphical  descrip- 
tion techniques,  e.g.  HyCharts,  in  comprehensive  tool 
frameworks,  such  as  accomplished  with  AUTOFOCUS 
for  discrete  systems. 

Note  that  the  development  process  for  hybrid  sys- 
tem proposed  in  [9]  can  be  regarded  as  an  intermedi- 
ary between  the  two  processes  outlined  here.  There, 
the  authors  propose  to  complement  block  diagrams 
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and  automata-based  notations  with  formal  specifica- 
tions using  Z [34], 

4 AutoFocus 

AutoFocus  [19,  20]  is  a tool  for  graphically  speci- 
fying embedded  systems.  It  supports  different  views 
on  the  system  model:  structure,  behavior,  interac- 
tion, and  data  type  view.  Each  view  concentrates  on 
a fixed  part  of  the  specified  model. 

Structural  view:  SSDs.  In  AutoFocus,  a dis- 
tributed system  is  a network  of  components,  possibly 
connected  one  to  another,  and  communicating  via  so- 
called  channels.  The  partners  of  all  interactions  are 
components  which  are  specified  in  System  Structure 
Diagrams  (SSDs).  Figure  4 shows  a typical  SSD.  In 
this  static  view  of  the  system  and  its  environment, 
rectangles  represent  components,  and  directed  lines 
visualize  channels  between  them.  Both  are  labeled 
with  a name.  Channels  are  typed  and  directed,  and 
they  are  connected  to  components  at  special  entry 
and  exit  points,  so  called  ports.  Ports  are  visualized 
by  filled  and  empty  circles  drawn  on  the  outline  (the 
interface)  of  a component.  As  SSDs  can  be  hierar- 
chically refined,  ports  may  be  connected  to  the  inside 
of  a component.  Accordingly,  ports  which  are  not  re- 
lated to  a component  are  meant  to  be  part  of  unspec- 
ified components  which  define  the  outside  world  and 
thus  the  component’s  interface  to  its  environment. 
Components  can  have  local  variables  to  store  values; 
these  variables  can  be  used  to  describe  the  behavior 
and  the  interaction  of  components. 

Behavioral  view:  STDs.  The  behavior  of  an  Au- 
toFocus component  is  described  by  a State  Transi- 
tion Diagram  (STD).  Figures  5 and  6 show  typical 
STDs.  Initial  states  are  marked  with  a black  dot. 
An  STD  consists  of  a set  of  control  states , transi- 
tions and  local  variables.  The  set  of  local  variables 
builds  the  automaton’s  data  state.  Hence,  the  inter- 
nal state  of  a component  consists  of  the  automaton’s 
control  as  well  as  its  data  state.  A transition  can 
be  complemented  with  several  annotations:  a label, 
a precondition,  input  statements,  output  statements, 
and  a postcondition,  separated  by  colons.  The  pre- 
condition is  a boolean  expression  that  can  refer  to 
local  variables  and  transition  variables.  Transition 
variables  are  bound  by  input  statements,  and  their 
life-cycle  is  restricted  to  one  execution  of  the  tran- 
sition. Input  statements  consist  of  a channel  name 
followed  by  a question  mark  and  a pattern.  An  out- 
put statement  is  a channel  name  and  an  expression 
separated  by  an  exclamation  mark.  The  expression 
on  the  output  statement  can  refer  to  both  local  and 
transition  variables.  A transition  can  fire  if  the  pre- 
condition holds  and  the  patterns  on  the  input  state- 
ments match  the  values  read  from  the  input.  After 
execution  of  the  transition  the  values  in  the  output 


statements  are  copied  to  the  appropriate  ports  and 
the  local  variables  are  set  according  to  the  postcon- 
dition. Actually  the  postcondition  consists  of  a set  of 
actions  that  assign  new  values  to  local  variables,  i.e. , 
the  assignments  set  the  automaton’s  new  data  state. 

Communication  semantics.  AutoFocus  com- 
ponents have  a common  global  clock,  i.e.,  they  all 
perform  their  computations  simultaneously.  The  cy- 
cle of  a composed  system  consists  of  two  steps:  First 
each  component  reads  the  values  on  its  input  ports 
and  computes  new  values  for  local  variables  and  out- 
put ports.  After  the  clock  tick,  the  new  values  are 
copied  to  the  output  ports  where  they  can  be  ac- 
cessed immediately  via  the  input  ports  of  connected 
components  and  the  cycle  is  repeated.  This  results 
in  a time-synchronous  communication  scheme  with 
buffer  size  1.  Values  on  the  output  ports  are  copied 
over  the  channels  to  the  appropriate  input  ports  and 
the  cycle  is  repeated.  This  results  in  a non  blocking 
synchronous  communication. 

Interaction  view:  MSCs.  Message  Sequence 
Charts  (MSCs)  are  used  to  describe  the  interaction 
of  components.  In  contrast  to  Message  Sequence 
Charts  as  defined  in  [23],  AUTOFOCUS  MSCs  refer 
to  time-synchronous  systems.  In  the  following,  the 
term  MSC  always  denotes  these  time-synchronous  se- 
quence charts.  Progress  of  time  is  explicitly  modeled 
by  ticks  which  are  represented  by  dashed  lines.  All 
actions  between  two  successive  ticks  are  considered 
to  occur  simultaneously,  i.e.,  the  order  of  these  ac- 
tions is  meaningless.  An  action  in  an  MSC  describes 
a message  that  is  sent  via  a channel  from  one  com- 
ponent to  another. 

MSCs  can  be  used  to  describe  requirements,  sim- 
ulation traces,  counter  examples  (from  model  check- 
ing), and  test  sequences.  Figures  7 and  8 show  a 
typical  test  case  specification  as  well  as  a satisfying 
test  case  that  satisfies  it. 

Datatype  view:  DTDs.  For  the  specification  of 
user  defined  data  types  and  functions  AutoFocus 
provides  Data  Type  Definitions  (DTDs).  Definitions 
in  DTDs  are  written  in  a functional  style.  For  hybrid 
systems  functions  with  continuous  ranges  can  be  de- 
fined, for  instance: 

const  GMars  = 3.73; 

fun  speed(last :Float ,dt :Float) 

= last+GMars*dt . 

Features  of  AutoFocus.  In  addition  to  its  model- 
ing capabilities,  AutoFocus  allows  for  checking  con- 
sistency between  views  as  well  as  simulating  models 
(using  OCL).  For  the  German  BSI  (Federal  Agency 
for  Security  in  Information  Technology)  several  val- 
idation techniques  have  been  integrated  into  Auto- 
Focus [33].  The  result  is  a model  validation  frame- 
work that  supports 

• model  checking  and  bounded  model  checking  to 
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check  temporal  properties  (invariants)  [31], 

• abstraction  techniques  to  safely  reduce  complex 
models  to  simpler  ones, 

• interactive  theorem  proving  techniques  to  verify 
arbitrary  security  requirements,  and 

• systematic  generation  of  test  sequences  and  test 
cases  [39,  26,  27]. 

All  these  validation  techniques  are  based  on  the  sim- 
ple and  intuitive  semantics  of  AutoFocus  [21],  and 
can  be  used  to  support  model-based  development 
steps.  This  framework  also  allows  to  generate  Java 
and  C code  from  the  validated  models  in  order  to  get 
executable  implementations. 

5 The  Mars  Lander 

This  section  describes  our  example,  a spaceship  sim- 
ilar to  the  doomed  Mars  Polar  Lander  that  allegedly 
did  not  complete  its  mission  due  to  a faulty  design  [8]. 
The  discretization  technique  we  apply  is  common  in 
the  design  of  discrete-time  control  systems  [30] . The 
next  section  then  shows  how  automated  test  genera- 
tion could  have  helped  in  avoiding  this  problem. 

Behavior.  The  hybrid  system  and  its  environ- 
ment may  be  described  by  four  main  distinct  states: 
The  lander  may  be  orbiting  (orbiting)  or  falling 
freely  after  leaving  its  orbit  (Rockets  Off).  Fur- 
thermore, the  lander  may  have  ignited  its  retro  rock- 
ets (Rockets  On)  in  order  to  slow  down  its  vertical 
movement,  and  ant  it  may  have  landed  (Landed). 
While  orbiting,  the  lander’s  vertical  speed,  ve(t),  is 

Vt(t)  » 0.0  (1) 

Diit)  — V/(fo)  Ri  I 9mars  dt  — Omars  ' if  ~ ^o)  (2) 

■Ho 
pt 

Vl{t)  ft!  / [Omars ^777  ’ Vf)dt  + Vt{t0)  (3) 

Jto  rant; 

rhi  » / (ci  • (vt(t)  - vreq)  + c2  • Vi)dt  (4) 
Jto 

Figure  2:  Mars  Lander  or  biting/ landed  (1),  falling 
without  (2)  and  with  (3,4)  rockets. 

zero  (Fig.  2-1).  This  behavior  is  also  exhibited  when 
the  lander  has  landed.  Once  it  has  left  its  orbit,  we 
assume  it  is  freely  falling  without  friction.  Its  be- 
havior can  thus  be  described  by  Fig.  2-2  where  the 
planet’s  gravity,  gmars,  is  assumed  to  be  constant. 
Strongly  simplifying,  the  system’s  dynamic  behav- 
ior in  state  RocketsOn  may  be  modeled  as  follows. 
Let  Fw(t)  rs  Omars  ■ m.;(f)  be  the  lander’s  weight 
force  with  m;(t ) being  the  lander’s  mass.  Further- 
more, let  Fthr(t)  = the  ■ Vf  be  the  rocket’s  thrust 


force  where  m;  is  the  lander’s  (negative)  change  of 
mass  and  vj  the  (negative,  approximately  constant) 
rocket’s  exhaust  speed.  By  ignoring  friction  effects 
and  letting  h(t)  denote  the  lander’s  height  one  de- 
rives h « Omars  ~ • Vf  and  thus  the  lander’s 

vertical  speed  (Fig.  2-3)  from  F(t)  ps  me(t)  ■ h = 
Fw(t)  — Fthr(t).  For  simplicity’s  sake,  horizontal 
forces  have  been  ignored.  Oversimplifying  again,  we 
furthermore  assume  a simple  PD  controller  for  the 
lander,  modeled  by  to;  ps  ci  • (v;(f)  - vre(])  + c2  • ve 
for  adequate  gains  Ci,C2  and  the  lander’s  required 
speed,  vreq.  This  yields  the  system’s  second  descrip- 
tive equation  (Fig.  2-4)  for  this  state.  The  control 
variable  is  thus  to;  (or  to;,  respectively)  which  re- 
flects an  increase  or  decrease  in  fuel  to  be  burnt. 

In  order  to  model  the  system  with  AutoFocus, 
the  above  equations  have  to  be  discretized  (i.e.,  lin- 
earized). Being  the  results  of  two  AutoFocus  sim- 
ulations, the  curves  in  Fig.  3 have  been  obtained  af- 
ter discretization  with  step  size  At  = .01.  It  shows 
height  and  velocity  for  two  behaviors  of  the  space- 
ship. After  a certain  time,  it  is  caused  to  start  its 
landing  procedure  by  leaving  the  orbit  (event  “en- 
ter”; events  are  symbolized  by  long  vertical  arrows). 
When  a maximum  speed  (45  m/s)  is  reached,  the 
rockets  are  ignited  (“rocketsOn”).  Some  time  later, 
the  legs  are  caused  to  open.  From  now  on,  the  behav- 
iors differ.  The  intended  behavior  is  that  when  the 
spaceship  actually  lands,  it  should  turn  off  its  rockets 
(trajectories  with  annotation  “rockets  on”).  Ground 
contact  is  inferred  from  a shock  in  the  legs. 

If,  on  the  other  hand,  opening  the  legs  causes  the 
rockets  to  be  switched  off,  velocity  immediately  in- 
creases which  results  in  a crash  (trajectories  anno- 
tated with  “rockets  off”).  This  is  what  allegedly  hap- 
pened to  the  real  spaceship:  Opening  and  adjusting 
the  legs  caused  some  sensors  in  the  lander  to  believe 
the  spaceship  had  landed  for  the  legs  sensed  a shock. 
(According  to  [8],  engineers  were  well  aware  of  this 
problem.  When  testing  the  system,  they  encountered 
a wiring  problem,  fixed  it,  and  did  not  re-run  their 
tests.  Nonetheless,  we  will  use  this  example  as  a mo- 
tivation for  a semi-automated  generation  of  test  cases 
in  Sec.  6.) 

Structure.  The  above  equations  show  that  two 
main  variables  are  involved,  namely  the  change  of 
mass,  to,;,  and  the  lander’s  vertical  speed,  v;(t).  This 
motivates  the  systems  top  level  structure  as  described 
by  the  SSD  in  Fig.  4 that  consists  of  three  com- 
ponents: a Lander,  a Physics,  and  a Controller 
component.  All  components  receive  the  current  time 
via  channel  T from  the  environment.  The  value  of 
T is  assumed  to  be  present  throughout  every  time 
slice,  and  to  be  increased  by  a constant  value.  The 
controller  sends  control  commands  to  the  other  com- 
ponents, in  order  to  switch  the  lander’s  rockets  on 
and  off,  to  enter  the  landing  phase,  and  to  open  the 
legs  for  landing.  It  has  a local  variable  CState  to 
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Figure  3:  Spaceship  crashes  and  lands. 


record  the  spaceship’s  state  since  it  needs  to  know 
when  to  issue  which  command.  The  initial  value  of 
this  variable  is  Waiting;  the  type  of  this  variable 
is  a DTD  data  CState  = Waiting  | Ron  | Roff. 
When  port  Sensor  receives  True,  this  should  (!)  in- 
dicate that  the  lander  has  sensed  ground  contact,  and 
in  turn  its  rockets  will  be  switched  off. 

The  differential  equations  of  Fig.  2-3  and  2-4  are 
mutually  dependent.  In  order  to  compute  the  val- 
ues independently,  the  computation  has  to  be  sepa- 
rated into  two  subcomponents,  namely  Lander  and 
Physics.  The  main  interaction  is  between  Lander, 
and  Physics:  the  environment  sends  the  current  ve- 
locity to  the  lander  (channel  ¥),  and  the  lander,  in 
turn,  sends  its  change  in  mass  to  the  environment 
(channel  Mdot).  Channel  Speed  is  only  necessary  for 
the  initial  value  of  the  control  process.  Lander  and 
Physics  could  have  been  grouped  together  into  one 
hierarchic  component.  This  is  advisable  if  systems 


become  more  complex.  The  behavior  of  component 
Physics  is  separated  into  two  states  (see  Fig.  5). 
State  Control  Off  just  outputs  the  current  speed 
(and  does  not  react  to  changes  of  mass),  whereas  in 
state  Control  On,  the  new  speed  is  computed  from 
the  last  speed  and  the  actual  change  in  mass  (Eq.  3). 
Component  Physics  has  several  local  variables  to 
store  past  values,  used  for  integration,  and  differen- 
tiation, LastTrFloat,  for  instance,  to  compute  time 
differences.  The  denotation  of  the  transition  labels 
in  Fig.  5 consists  of  functional  terms  computing  new 
values  according  to  the  discretized  equations.  The 
behavior  of  component  Lander  is  separated  into  four 
states  (see  Fig.  6),  each  representing  a differential 
equation  or  the  respective  computation  of  new  val- 
ues (mainly  for  the  local  variables:  LastT,  LastV, 
LastM,  LastH,  and  LegsDut)  and  for  the  output  Mdot. 
In  the  initial  state  Orbiting  the  lander  waits  for  the 
command  enter  from  the  controller  (received  at  port 
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Figure  6:  Behavior  of  Component  Lander 


Local  Variables: 


Figure  4:  System  Structure  Diagram 


Control).  Unless  no  enter  command  is  present,  ini- 
tial values  are  sent  to  the  environment.  This  is  done 
within  the  transition  labeled  flying  and  the  follow- 
ing semantics: 

• input  pattern  Control?  denotes  no  input  on 
port  Control, 

• input  pattern  T?t  denotes  that  the  input  on  port 
T is  bound  to  transition  variable  t, 

• output  patterns  Height  ILastH,  and 
Speed  ILastV  denote  the  sending  of  the  current 
values  of  the  variables  to  the  output  ports, 

• action  LastT  = t stores  the  value  t into  the  lo- 
cal variable  LastT. 


Figure  5:  Behavior  of  Component  Physics 


This  last  transition  has  no  precondition  (since 
t>LastT  is  a general  assumption  on  time). 

The  states  Rockets  On  and  Rockets  Off  control 
the  lander  during  the  landing  phase  (with  and  with- 
out boosters);  control  commands  RocketsOn  and 
RocketsOf  f from  port  Control  can  be  used  to  switch 
between  the  two  respective  equations.  If  the  height 
is  less  or  equal  to  zero  in  one  of  the  states,  the  lander 
reaches  the  final  state  landed. 

Shortcomings.  Suitably  discretizing  a continu- 
ous model  is  a difficult  problem.  We  chose  a simple 
piecewise  linearization  with  trapezoidal  approxima- 
tion. Problems  with  this  approach  include  a con- 
servative determination  of  At  as  well  as  meaningful 
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error  estimations.  Thus  far,  we  use  the  same  At  for 
all  components  (in  accordance  with  user-defined  step 
sizes  for  each  component).  This  approach  may  re- 
sult in  efficiency  problems,  but  it  solves  the  problem 
mentioned  below  for  communicating  components  in- 
tegrating over  a same  variable  in  the  case  this  variable 
is  t.  The  automatic  generation  of  discretized  systems 
from  continuous  equations  is  subject  of  ongoing  work. 
Especially  methods  are  developed  to  break  systems  of 
differential  equations  into  single  components,  to  de- 
termine appropriate  discretization  methods,  and  to 
to  find  good  timing  rates  for  the  components. 

6 Testing 

Approaches  to  ensure  a system’s  reliability  include 
validating  a model  w.r.t.  its  specification  as  well  as 
checking  an  implementation’s  conformance  w.r.t.  the 
specification.  Formal  methods,  such  as  model  check- 
ing, allow  for  determining  a system’s  correctness  in 
terms  of  user  defined  properties  usually  formulated  in 
an  (unintuitive)  logic,  e.g.,  the  Linear  time  Temporal 
Logic  LTL.  Without  suitable  (and  usually  hard  to  de- 
termine) abstractions,  model  checking  is  restricted  to 
finite  state  spaces  which,  for  instance,  typically  grow 
exponentially  with  the  number  of  variables  involved. 
Not  surprisingly,  industrial  applicability  has  not  yet 
been  achieved.  In  the  following,  we  describe  how  a 
classical  approach  to  quality  assurance,  namely  test- 
ing, is  supported  by  AutoFocus.  We  advocate  an 
integration  of  mathematically  complete  techniques 
(model  checking)  with  testing.  In  addition  to  specify- 
ing test  cases  during  the  design  phase,  testing  should 
also  be  done  interactively,  for  certain  errors  can  only 
be  revealed  by  “playing  around”  with  the  model. 
This  kind  of  testing  may  thus  be  seen  as  a debugging 
aid.  This  is,  in  fact,  the  case  for  most  of  the  spec- 
tacular software  faults  the  model  checking/theorem 
proving  communities  use  as  a motivation  for  their 
work.  The  discussion  of  test  management  strategies 
and  particular  techniques  such  as  mutation  analysis 
and  fault  injection  is  beyond  the  scope  of  this  article 
and  thus  omitted. 

Applicability  and  Terminology.  We  distinguish 
between  possibly  informal  requirements,  a specifica- 
tion which  is  called  a model  if  it  is  written  down 
formally  (e.g.,  in  AutoFocus),  and  an  implemen- 
tation. Testing  an  implementation  is  usually  done 
w.r.t.  its  specification,  e.g.,  [32,  26,  27];  the  speci- 
fication is  thus  considered  to  be  correct.  Obviously, 
this  is  a strong  and  usually  unrealistic  assumption. 
However,  we  think  it  is  one  necessary  step.  The  tech- 
niques sketched  below  and  explained  in  more  detail 
in  [26,  27,  39]  allow  for  the  determination  of  test  se- 
quences on  the  grounds  of  a test  case  specification. 
A test  case  specification  is  the  formalization  of  some 
test  purpose,  i.e.,  reach  a particular  state  or  cause 
the  system  to  throw  a particular  exception.  Test 


case  specifications  can,  for  instance,  be  written  down 
as  mathematical  formulas  [12],  formal  specifications 
[37,  5,  32],  as  MSCs  [13,  26,  27,  39],  as  partial  I/O 
traces  or  constraints  over  them  [26,  27,  7].  A test  case 
is  an  artifact  that  satisfies  a given  test  case  specifi- 
cation and  may  be  formulated  in  the  same  forms  as 
test  case  specifications.  A test  sequence,  finally,  is  an 
executable  test  case,  e.g.,  an  I/O  trace.  [27]  discusses 
this  terminological  framework. 

Our  work  aims  at  (semi-)  automatically  deriving 
test  cases  from  test  case  specifications  that  may  be 
used  for  both,  interactively  white  box  testing  a spec- 
ification and  (semi-)  automatically  black  box  testing 
an  implementation.  As  indicated  above,  the  interac- 
tive part  plays  an  important  role  in  the  development 
process.  Even  though  it  is  undoubtedly  true  that  a 
system  should  be  thoroughly  thought  over  before  it 
is  implemented  or  modeled,  we  believe  that  simula- 
tion and  interactive  testing  help  in  understanding  a 
model.  This  is  related  to  the  rapid  prototyping  ap- 
proach in  software  engineering;  we  even  see  simula- 
tion as  a specialization  of  the  testing  process  [26,  27]. 

However,  it  is  worth  emphasizing  that  most  likely 
none  of  the  commonly  used  approaches  to  quality  as- 
surance will  do  it  alone.  In  contrast  to  formal  meth- 
ods testing  is  an  inherently  incomplete  process.  As 
formal  methods  yet  do  not  scale  to  real  size  applica- 
tions, this  deficit  has  to  be  accepted  but  borne  in 
mind.  Dijkstra’s  popular  remark  that  testing  can 
only  reveal  the  presence  but  never  the  absence  of  er- 
rors also  applies  to  formal  methods:  One  can  only 
check  properties  that  have  been  formulated  by  a hu- 
man. This  process,  however,  obviously  is  also  neces- 
sarily incomplete. 

Test  case  specification.  The  specification  of 
test  cases  or  properties  to  be  checked  requires  in- 
tuitive and,  if  possible,  graphical  description  tech- 
niques. One  problem  with  formal  techniques  surely 
lies  in  the  fact  that  without  an  intense  formal  edu- 
cation properties  are  hard  to  express  in  formalisms 
such  as  LTL  or  the  Temporal  Logic  of  Actions  TLA 
[25].  We  hence  advocate  the  use  of  a variant  of  Mes- 
sage Sequence  Charts  [23]  for  the  specification  of  test 
cases  [13,  39,  26,  27].  MSCs  (HySCs)  are  augmented 
with  elements  for  talking  about  states  in  condition 
boxes  [15]  as  well  as  constructs  for  expressing  itera- 
tion and  the  necessity  of  certain  transitions  to  fire. 
The  identification  of  typical  test  purposes,  e.g.,  caus- 
ing the  system  to  output  certain  values,  reaching 
states,  executing  transition  sequences  [39],  led  to  the 
incorporation  of  these  language  constructs. 

An  important  concept  is  that  of  negation  (negating 
transitions,  the  reachability  of  states,  or  forbidding 
certain  inputs  or  outputs).  However,  a suitable  se- 
mantics for  MSCs  in  the  context  of  test  cases  seems 
to  be  incomplete  in  the  sense  that  between  two  el- 
ements in  an  MSC,  arbitrarily  many  others  may  be 
present.  Apparently  the  formal  definition  of  a se- 
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mantics  for  negation  in  this  context  is  not  obvious 
[24]  and  subject  of  ongoing  work. 

In  AutoFocus,  test  cases  may  be  specified  by 
both  LTL  formulas  and  MSCs.  In  the  following, 
we  focus  on  the  derivation  of  test  cases  from  sys- 
tem and  test  case  specifications.  In  the  remainder 
of  this  section,  the  system  specification  should  be 

thought  of  as  an  AutoFocus  model,  and  the  test 
case  specification  is  formulated  using  MSCs.  Com- 
puted test  cases  (I/O  sequences)  are  displayed  in  the 
form  of  MSCs  themselves  for  inspection  by  a human 
(or  comparison  with  expected  test  results,  i.e.,  corre- 
spondence of  the  model’s  output  with  the  output  as 
described  in  the  test  case  specification).  Note  that  in 
this  paper  we  concentrate  on  testing  a specification 
and  do  not  take  into  account  testing  implementations 
even  though  computed  test  sequences  can  be  fed  into 
an  implementation  for  conformance  testing  with  the 
specification. 

Testing  discrete  systems.  This  paragraph  briefly 
describes  the  generation  of  test  cases  from  test  case 
specifications  by  means  of  Constraint  Logic  Program- 
ming (CLP)  as  well  as  of  propositional  logic.  These 
methods  automatically  derive  test  sequences  from 
system  and  test  case  specifications. 

CLP  is  the  result  of  integrating  two  declarative 
programming  paradigms,  namely  logic  and  constraint 
programming.  Distinctive  features  include  inverta- 
bility  of  functions,  the  use  of  free  (logical)  variables 
that  may  be  bound  during  program  execution,  built- 
in  search  mechanisms  - backtracking  and  a seman- 
tics based  not  only  on  terms  but  rather  on  arbitrary 
domains.  It  turned  out  that  AutoFocus  models 
can  very  naturally  be  translated  into  CLP  languages. 
The  idea  is  to  feed  the  executable  model  with  partial 
I/O  traces  and  make  the  test  case  generation  sys- 
tem create  actual  test  cases  (possibly  partial  I/O  se- 
quences subject  to  certain  constraints,  e.g.  ranges  for 
variables)  by  relying  on  the  above  mentioned  built-in 
search  mechanism  and  by  using  logical  variables.  By 
imposing  constraints  (e.g.,  in  the  forms  of  MSCs)  on 
the  set  of  all  possible  system  execution,  the  search 
space  can  significantly  be  reduced.  Further  analyses 
such  as  automated  interval  analyses  or  (manually  de- 
rived) classification  trees  [14]  for  variables  then  allow 
for  the  determination  of  meaningful  test  sequences 
(taking  into  account,  for  instance,  range  boundaries 
that  yield  equivalence  classes  to  be  tested).  [26,  27] 
contain  a more  detailed  description  of  this  approach. 

Testing  based  on  propositional  logic  is  suitable 
only  for  small  finite  systems  (in  particular,  for  sys- 
tems with  small,  finite  variable  ranges).  AutoFocus 
models  as  well  as  test  case  specifications  are  trans- 
lated into  propositional  logic  and  combined  into  a sin- 
gle formula  which  is  fed  into  a propositional  solver. 
The  results  (binding  of  free  variables  in  traces)  are 
translated  back  into  MSCs.  A detailed  description 
of  this  approach  which  is  related  to  bounded  model 


Figure  7:  Test  case  spec.:  Reach  state  landed. 
checking  [2]  can  be  found  in  [39]. 

Testing  hybrid  systems.  In  principle,  the  above 
automatic  CLP  based  generation  of  test  sequences  is 
also  applicable  to  mixed  discrete-continuous  systems, 
for  numerical  or  algebraic  solvers  can  easily  be  con- 
nected to  the  CLP  system.  Yet,  assuming  that  con- 
tinuous activities  take  place  within  particular  states 
of  the  system  and  that  there  is  a continuous  data  flow 
between  components,  a number  of  problems  arise. 
First  of  all,  it  is  not  clear  how  a continuous  data  flow 
can  be  simulated  on  ordinary  computers  (in  control 
systems,  however,  there  indeed  is  a continuous  flow  of 
data).  Secondly,  numerical  solvers  also  discretize  dif- 
ferential equations  and  solve  these  equations  with  dif- 
ferent, possibly  even  dynamic,  integration  step  sizes. 
It.  is  not  clear  how  to  handle  the  situation  where  one 
component  triggers  a transition  dependent  on,  e.g., 
the  global  time.  Assume  that  two  components  run  at 
different  speeds,  i.e.,  with  different  integration  step 
sizes.  If  one  component  integrates  over  a common 
variable  and  meanwhile  receives  a value  for  exactly 
this  variable  that  has  been  determined  according  to 
an  earlier  time,  it  has  to  stop  its  integration  process 
and  to  step  back.  This  results  in  severe  methodical 
as  well  as  efficiency  problems,  both  of  which  are  sub- 
ject of  ongoing  work,  based  on  (1)  the  semantics  for 
hybrid  systems  as  defined  in  [35]  and  (2)  a modifica- 
tion of  the  AutoFocus  semantics  where  continuous 
activities  do  not  take  place  on  transitions  but  rather 
within  states.  This  applies  only  to  hybrid  testing 
since  real  time  simulation  forbids  re-calculating  cer- 
tain variable  boundaries. 

Example:  Testing  the  lander.  In  accordance 
with  these  considerations,  so  far  the  methods  for  de- 
riving test  cases  described  above  have  only  been  im- 
plemented for  discrete  systems.  As  AutoFocus  is 
based  on  an  inherently  time-discrete  semantics,  this 
paragraph  illustrates  the  derivation  of  test  sequences 
for  the  discretized  model  of  the  Mars  lander.  Due 


15-11 


Figure  8:  Test  case:  Lander  crashes. 

to  space  limitations,  we  concentrate  on  just  one  test 
case  specification  which  is,  however,  sufficient  to  con- 
vey the  principal  idea.  Figure  7 shows  the  graphical 
specification  for  the  test  case  “find  a system  run  that 
makes  component  lander  reach  state  landed’ . A de- 
rived corresponding  test  case  specifying  this  specifica- 
tion is  depicted  in  Fig.  8.  Note  the  close  relationship 
with  the  State  Transition  Diagram  of  Fig.  5.  This 
system  run  makes  the  lander  crash  for  its  final  ve- 
locity when  touching  the  ground  is  much  too  high 
(approximately  67  m/s).  Obviously,  this  is  just  one 
test  case  for  the  given  specification.  Another  suc- 
cessful run  leaves  the  rockets  ignited  until  the  space- 
ship actually  has  had  ground  contact.  Both  possible 
runs  are  depicted  in  Fig.  3 in  forms  of  the  respec- 
tive variables’  trajectories.  Note  that  in  case  of  the 
crash  there  is  no  automated  means  for  assessing  the 
outcome  of  a test  case,  nor  some  help  in  order  to  de- 
tect the  fault.  Above,  we  described  two  possible  test 


scenarios,  one  of  which  consisted  of  test  case  specifi- 
cations with  verdicts  and  has  been  created  indepen- 
dently of  the  modeling  process.  The  second  scenario 
is  closer  to  the  area  of  rapid  prototyping,  where  test- 
ing is  seen  as  a debugging  aid.  In  the  case  of  Fig.  8, 
both  scenarios  may  apply.  However,  there  obviously 
is  need  for  an  engineer  who  derives  from  the  test  se- 
quence that  using  a shock  in  the  legs  as  ground  de- 
tection mechanism  is  a bad  idea! 

7 Conclusion 

A central  aim  of  our  work  is  the  support  of  a sys- 
tematic design  of  correct  safety-critical  hybrid  em- 
bedded systems.  For  discrete  systems  we  think  that 
a number  of  effective  validation  and  verification  tech- 
niques has  been  integrated  within  the  AutoFocus 
framework.  In  this  paper  we  presented  an  example 
of  an  ad-hoc  discretization  of  a hybrid  system,  using 
discrete  formal  models.  The  model  allowed  an  im- 
proved validation;  in  particular,  important  test  sce- 
narios have  been  derived.  Secondly,  precise  require- 
ments for  dealing  with  hybrid  systems  in  the  con- 
text of  discrete  CASE  tools  have  been  obtained:  (1) 
systematic  discretization  support,  and  (2)  extending 
formal  modeling  and  validation  methods  with  con- 
tinuous features  to  hybrid  methods.  Thirdly,  a new 
development  process  for  hybrid  systems  has  been  pro- 
posed and  discussed. 

In  the  future  we  will  further  evaluate  how  Auto- 
Focus  can  be  applied  in  the  development  of  safety 
critical  avionic  systems  and  what  is  necessary  to 
make  it  compatible  with  the  certification  process  re- 
quired for  such  systems.  Furthermore,  a testing  med- 
hodology  (which  test  cases  to  choose,  how  many,  etc.) 
is  the  subject  if  future  work. 
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